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Description 

This invention relates in general to electronic calendaring methods, and in particular, to a calendaring 
method in which replies to requests from calendar owners to participate in a future calendar event are 
5 generated automatically, based on criteria pre-established by a receiving calendar owner or by default 
criteria established by the calendaring method. 

The prior art has disclosed a number and variety of interactive electronic calendaring systems and 
method. The objective of all of these systems is primarily to assist the person who, for a number of different 
reasons, maintains a calendar of future events containing various information about the event at entry points 
10 on the calendar which relate to the time of the event. 

The increase of personal computers and intelligent workstations in recent years has made it possible for 
calendar owners to establish and maintain their calendars on these interactive type data processing 
systems. 

Two general types of interactive electronic calendaring systems have thus evolved in the art. In one 

75 type of calendaring system, the owner of the calendar is generally also the user of the workstation and that 
workstation is generally not a part of a larger network. Generally, in these types of systems, the calendar 
functions involve presenting a screen to the user representing day calendar divided into a number of time 
periods or time slots. Each period is capable of displaying a limited amount of text that the user enters. In 
some systems, the day calendar can scroll vertically to present more time periods to the user or 

20 horizontally to present longer text entries. The operator can generally "page" forward or backward and, in 
most arrangements, can display a requested date. These calendaring arrangements generally do not limit 
the type of event that is calendared nor the terminology employed at any of the entry points and, to that 
extent, function in the same manner as conventional manual calendars or appointment books. The 
electronic calendaring method and systems do have an advantage over the prior art manual calendaring of 

25 events in that the user generally has the ability to scan a time span involving a large number of days and 
identify calendared events quite rapidly. 

The other type of calendaring arrangement that has developed in the prior art involves multi-user 
environments having a large number of terminals or workstations which are generally part of a larger 
communication network that has been established to permit the users to interact with each other and with 

30 data maintained on the data processing system. In this environment, a user at a terminal or workstation can 
send a message to one or more of the other users on the network and is notified when the addressees has 
received and read the message. 

In most of these environments, each user generally maintains a calendar, and in many of these 
environments the reason for the interaction with each other quite often generally involves reference to 

35 respective calendars. A considerable amount of time is therefore spent in many organizations, with people 
checking and rearranging their calendars to accommodate various events such as meetings, presentations, 
etc. In this environment, the calendar systems and method have progressed to the point where a person 
who is calling a meeting can at least review within the constraints that the security system dictates, the 
calendars of other users on the system that he intends to invite to a meeting, to determine whether a given 

40 time period is available on the respective calendars of the perspective attendees. 

The reference guide "USING THE PROFESSIONAL OFFICE SYSTEM", version 2, release 2, published 
in June 1986 by IBM Corporation, describes at pages 3.28 to 3.33 a prior art method wherein a screen is 
presented to the meeting originator which requests the data necessary for the system to determine times 
that all potential attendees would be available. The data requested includes, for example, the length of the 

45 meeting, a time period during which the meeting should be conducted, the place of the meeting and the 
names of the attendees. Based on this data, the method returns a screen of available times after inspecting 
each attendee's day calendar during the time period for free time slots or periods. The originator then 
selects the beginning time and end time of the meeting, including the time and date, and invitations are 
automatically sent to all the attendees, requesting their attendance at the scheduled meeting. 

so However, once the meeting time is set and the prospective participants notified of the date, time, and 
subject of the meeting, each participant must update his own electronic calendar and reply to the meeting 
request. 

The IBM Technical Disclosure Bulletin, Vol. 26, N° 11, April 1984, describes at page 6221 a 'confirm' 
function which lessens the burden of answering to a meeting notice by reducing it to a single key 
55 interaction. 

While this system can facilitate the request and reply message process, it is sometimes less frustrating 
when a negative reply has to be transmitted to merely use the telephone to arrive at another mutually 
convenient time. As a result, a considerable amount of time and effort is spent by calendar owners replying 
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to requests for participation in events that are being calendared by other persons. 

According to the invention, there is provided a calendaring method for use in a data processing system 
having a plurality of interactive type work stations connected directly or indirectly to a host processing unit 
and in which a first calendar owner receives a response from a second calendar owner as a result of an 
5 event notice sent through said system to said second calendar owner at the time said first owner is 
calendaring an event, said method selectively developing said response automatically, based on criteria that 
are pre-established by said second owner, said method comprising the steps of: 

a) establishing a first data structure for use by said system during the calendaring of an event by said 
first owner including a plurality of fields for storing data relevant to said event, 
10 b) establishing a second data structure for later use by said system in developing an automatic response 
upon receiving an event notice from said first owner, said second data structure including a plurality of 
predefined fields for storing data when they are entered into said system by said second owner, said 
data including criteria type data and response type data, 

c) comparing said criteria type data stored in said second data structure with data stored in said first 
75 data structure when said event notice is received by said second owner, and 

d) developing said response automatically when said comparing step indicates a predetermined relation- 
ship between one or more of said criteria type data and the corresponding respective data stored in said 
first data structure. 

An embodiment of the invention will now be described, by way of example, with reference to the 
20 accompanying drawings, in which: 

Fig. 1 is a block diagram of an interactive data processing terminal in which the method of the present 
invention may be advantageously employed; 

Fig. 2 is a block diagram of the network of terminals of the type shown in Fig. 1; 

Fig. 3 illustrates the display screen employed in the present invention for obtaining data that is used in 
25 developing an automatic reply; 

Fig. 4a through 4c illustrate display screens that are employed in connection with the method of the 
present invention for entering information interactively into the system during the event calendaring 
process; and 

Fig. 5 is a flow chart illustrating various detailed steps of the improved electronic calendar method 
30 involved in developing an automatic reply. 

Fig. 1 illustrates the functional components of an interactive type data processing terminal on which the 
electronic calendaring method of the present invention may be advantageously employed. The terminal 
comprises a processing unit 11 which includes a microprocessor block 12, a semiconductor memory 13, 
and a control block 14 which functions to control input/output operations in addition to the interaction 
35 between the micro processor block 12 and the memory unit 13. 

The terminal further includes a group of conventional peripheral units including a display device 16, a 
keyboard 17, a printer 18, a disk storage unit 19, and a modem 20. Since the details of the above described 
functional blocks form no part of the present invention and can be found in the prior art, only a brief 
functional description of each block is set forth, along with a description of their interactions, sufficient to 
40 provide a person of ordinary skill in the art with a basis of understanding applicants 1 improved electronic 
calendaring method. 

Processing unit 1 1 corresponds to the "system unit" of a personal computer system such as the IBM 
XT or IBM AT type systems. Unit 1 1 is provided with an operating system program which may be one of 
the many versions of DOS (Disk Operating System) which is normally employed to run the systems. The 

45 operating system program is stored in memory 13 along with one or more application programs that the 
user has selected to run. Depending on the capacity of memory 13 and the size of the application 
programs, portions of these programs, as needed, may be transferred to memory 13 from the disk storage 
unit 19 which may include, for example, a 30 megabyte hard disk drive and a diskette drive. The basic 
function of the disk storage unit is to store programs and data that are employed by the system and which 

so may readily be transferred to the memory unit 13 when needed. The function of the diskette drive is to 
provide a removable storage function for entering programs and data into the system, and a vehicle for 
storing data in a form that is readily transportable for use on other terminals or systems. 

Display device 16 and keyboard 17 together provide for the interactive nature of the terminal, in that in 
normal operation, the interpretation that the system gives to a specific keystroke by the operator depends, 

55 in substantially all situations, on what is being displayed to the operator at that point in time. 

In some situations, the operator, by entering commands into the system, causes the system to perform 
a certain function. In other situations, the system requests the entry of certain data, generally by displaying 
a prompt type of menu/message screen. The depth of the interaction between the operator and the system 
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varies by the type of operating system and the application program, but is a necessary characteristic of 
terminals on which the method of the present invention may be employed. 

The terminal shown in Fig. 1 further includes a printer 18, which functions to provide hard copy output 
of data developed or stored in the terminal. Lastly, the modem 20 functions to transfer data from the 

5 terminal of Fig. 1 to a host system through one or more communication links which may be a commercial 
type link or a dedicated communication link. 

Fig. 2 illustrates a network 21 of interactive type workstations of the type shown in Fig. 1. As illustrated, 
the network includes a plurality of terminals which are interconnected with each other and to a host central 
processing unit 23, which in turn is connected via communication link 24 to a second host processing unit 

70 25, which also connects to another network 26 of interactive workstations. Functionally, the system operates 
to allow one terminal to communicate to one or more other terminals using established communication 
protocols, so that the various serially connected communication links are transparent to the operator. Such 
systems are well known in the art, and are currently in extensive commercial use. Since these communica- 
tion links per se are not part of the present invention, only those details that are necessary for an 

75 understanding of the calendaring method of the present invention will be described. It should therefore be 
assumed in the following description, that each workstation on the network has a system node address and 
a "post office" address, and that to simplify the description, there is only one individual assigned to each 
node on the network. It should further be assumed that conventional communication services are provided 
by the system, such as directory listings of individual calendar owners and shareable resources such as 

20 meeting rooms, etc., which require scheduling. 

The system shown in Fig. 2 processes information as various types of data objects such as text data 
objects, graphic data objects, and calendar data objects. Each of these data objects are represented by a 
datastream which comprises a series of structured fields. 

A calendar object datastream has the following sequence of structures. 

25 

Begin Document (BDT) 
Begin Page (BPG) 
30 Begin Calendar Data (BCD 

Calendar Data Descriptor (CDD) (Optional) 
Calendar Data SF (CAD) 

35 

Calendar Structures (COCA) 



40 End Calendar Data (ECU 

End Page (EPG) 
End Document (EDT) 

45 

The format of the datastream for other type data objects contain the begin document, begin page, end 
page, and end document data structures. Structured fields corresponding to those listed above for a 
calendar object are also employed for other type objects. 

A structured field is a self-describing entity which contains related groupings of parameter values and 
50 triplets. The structure field, as shown below, has two parts: the Structured Field Introducer and the 
Structured Field Content. 





SF1 


PI 


P2 


P3 


/ I 
1 


55 













Pn 







n-1 
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The structured field begins with a Structured Field Introducer. The syntax and semantics of the Structured 
Field Introducer are defined by the architecture which governs the datastream in which the structured field 
is found. The Structured Field Introducer contains as the first two bytes a parameter which defines the 
length of the structured field. It also contains an identification code which uniquely identifies the structured 
5 field. 

The Structure Content portion of each structured field contains structures and triplets, which give the 
structured field its meaning. Parameters in the triplets define the attributes of the Calendar Object. Every 
parameter has a value either explicitly appearing in a triplet, inherited from a control structure in the 
datastream's hierarchy, or implicitly defined as a default. This default may also be the alternate action value. 
io Every structure is either required or optional. A required structure appears in the object because the 
function of that structure is required and for proper performance of the function an value is necessary. 

An optional structure need not appear in the object either because the function of that structure is not 
required or because the function is required, but default values are acceptable for all parameters. 

As shown above, a calendar data (CAD) structured field (SF) precedes the actual calendar data. A 
75 calendar data descriptor (CDD) SF can precede the CAD SF to provide formatting information for the data 
that follows. 

Calendar data comprises named data structures and named triplets which are composed of parameters. 
A parameter is a variable to which a value is assigned. Parameters can be optional or required. Parameters 
are also classified as terminal or non-terminal. A terminal parameter is merely the last parameter in a string 
20 of parameters. 

A parameter can have one of three types of values assigned. 

1. NUM - This is a number or a numerical value. 

2. COD - This is a code assigned a specific meaning. 

3. BST - This is a bit string of binary elements, each of which is usually independent of the other. 

25 In the following discussion it will be assumed that a byte comprises 8 bit positions numbered 0-7 from 
left to right, with position 0 being the high order position. Bit position 0 represents 2"7 (2 to the 7th power), 
while bit 7 represents 2**0 (2 to the 0 power). 

The various calendar structured fields and calendar triplets are defined by the following type of table. 



30 



I BYTES 


J NAME 

t 


{ TYPE 


MIN 


MAX JlGTH| OPT I 
I I i 


' n - m 


i name 


! type 


V 


x [www ! 



35 

In the figure: 

- BYTES refers to the position, indexed on zero. 

- NAME is the name by which reference is made to the parameter. 

- TYPE denotes the syntax of the parameter by "type," The architected types NUM, COD, and BST 
40 were described earlier. 

- LGTH denotes the length of the field in terms of the exact number of bytes or the maximum number 
of bytes permitted. 

- OPT refers to the optionality of the parameter's appearance in the structure or triplet: 
0 means that the parameter is optional. 

45 R means that the parameter's appearance is required. 

If a required parameter is missing, an exception condition exists. The alternate action is to ignore 
the structure, self-defining field, or triplet to which the missing parameter belongs. 
Syntactically descriptive material below the figure indicates what additional restrictions apply to the 
structure or triplet defined by the figure, 
so Calendar structures and calendar triplets which are relevant to the present invention will be described 
using the above-described format. After the structures are described, the display screens that are presented 
to calendar owners by the system in order to solicit information when a calendar owner wants to perform a 
calendaring function will be described. A flow chart setting forth the detailed steps of the method of the 
present invention will then be described in connection with the program listing of pseudocode that will assist 
55 persons skilled in programming interactive terminals to implement the method of the present invention. 

Since the Automatic Response function operates in response to an invitation to an event being 
calendared by another calendar owner, it is necessary to describe in detail the data structures that are 
employed by the system in the process of an owner calendaring an event on his calendar. In the preferred 
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embodiment, calendar entries are classified into a number of different types. Since the system con- 
templates interchanging calendar data throughout the system, including terminals that are remotely 
connected, such as those shown in Fig. 2, entry types and presentation language are controlled by a 
defined architecture. 

5 While the same display screen may be employed to solicit the data for a number of different event 
types, the data structures and triplets, required or optional, will vary by event type. 

While some of the structures to be described and the triplets associated with these structures are not 
directly involved in the "Automatic Response"function, they have been described in order to provide 
background for the reader and a basis for a comprehensive understanding of the claimed process and its 
w relationship to the processes described and claimed in the cross-referenced application. 

The various calendar object data structures to be described are preceded by a calendar data structure 
shown below. 



CALENDAR DATA (CAD) STRUCTURE FIELD (SF) 


BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


0-1 


Structured Field Length 


NUM 


8 


32767 


2 


R 


2 


Structured Field Typel 


COD 


X'D3' 


X'D3' 


1 


R 


3 


Structured Field Type2 


COD 


X'EE' 


X'EE 1 


1 


R 


4 


Structured Field Type3 


COD 


X'5B' 


X'5B' 


1 


R 


5 


Flags 


BST 


0 


0 


1 


R 


6-7 


Segment Sequence Number 


NUM 


0 


32767 


2 


R 


8-7 + n 


Calendar Data 




* 


* 


n 


R 


" Values depend on the Calendar Object structure and triplet specification. 



The Calendar Data SF (CAD) identifies the data as calendar data and specifies the length of the 
calendar data. The Calendar Data SF contains, for example, up to 32767 bytes of calendar structures and 
calendar triplets (called "Calendar Data"). Calendar data varies with the function employed by the generator 
of the object. 



MAJOR CALENDAR STRUCTURES DESCRIPTION 



This section describes the major structures that are involved in the present invention. The structures 
consist of a mixture of calendar triplets. The triplets are described in the Calendar Triplets Description 
section that follows this section. 

The calendar structures are preceded by the Calendar Data structured field (CAD). Parameter values 
specified by the system can be overridden by parameters specified in calendar data. For example, the 
Code Page of Symbols for Displaying and Printing Data. 

In the structure description, bits are consecutively numbered from left to right starting with zero. 

The format for all of the structures is the same. The format is shown below. 





' BYTES 


! NAME 
1 


i TYPE 


! MIN 


MAX |lGTH[ OPT 


50 


! 0 - 1 


I LENGTH 
I 


! NUM 




! ! R 




! 2 - 3 


! TYPE 
i 


! COD 




! ! ! r 




! 4 - n 


! TRPLTl to TRPLTn 






! ! ! r 



55 



where 

LENGTH = A two-byte value of the number of bytes in this structure including byte zero. 
TYPE = A two-byte binary number that designates a specific structure function. 
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TRPLT1 TO TRPLTn = Calendar Structure Triplets. 

The length of structures can vary depending on the number of triplets included. 
If the length excludes all or part of an optional parameter in a triplet, then the value for that parameter 
and any parameters that follow are not changed; that is, the LENGTH field is used as specified. 
5 If a structure is invalid or unsupported, an exception is raised. 

If the length field excludes a required parameter or triplet, an exception is raised. 

If a structure contains an invalid or unsupported parameter or triplet, an exception is raised. 



MEETING (MTG) STRUCTURE 

10 

The meeting structure is shown below. 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


0-1 


Structure Length 


NUM 


* 


32767 


2 


R 


I 2 


Structure Typel 


COD 


X'D#' 


X'D3* 


1 


R j 


3 


Structure Type2 


COD 


X'85' 


X'85' 


1 


R 


4-3 + n 


Meeting Triplets 




* 




n 


R 


" Values depend on the triplet specification. 



The MTG structure provides the fields necessary to interchange meeting information, the scheduling of 
meetings and requests for meeting information. It also provides a specific search classification to allow 
building a composite calendar for a specified list of calendar owners. 

The Valid MTG Triplets are listed below and defined in detail in the following section. 

ERROR ACTION (EAC) - An EAC triplet may occur in any sequence and is optional. 

STRUCTURE ID (SID) - The SID specifies the ID for the meeting.An optional SID may be included to 
identify a Trigger (TRG) associated with the meeting. 

DATE AND TIME (DTT) - The DTT triplet provides the meeting time(s) and date(s) and is required. DTT 
triplets must occur in ascending time(s) and date (s). A meeting that occurs at non-sequential times can be 
scheduled by using more than one DTT triplet specifying the required times. 

NAME (NME) - Network Address (NAD), Postal Addresses (PAD) and User Status (UST) triplets may be 
used to provide user status and addresses for a named item. NME triplets and associated NAD, PAD and 
UST triplets may be included for both the CALLER (meeting owner) and the ARRANGER (meeting 
arranger). The Name Status byte specifies whether or not NAD, PAD and UST triplets follow the Name 
triplet which is optional. 

USER STATUS (UST) - The UST triplet provides the role and status for the person named in the NME 
triplet. This triplet is only valid when it follows a NME triplet and is optional. 

NETWORK ADDRESS (NAD) - The NAD triplet provides the network address for the person named in 
the NME triplet and is optional. 

POSTAL ADDRESS (PAD) - The PAD triplet provides the the mailing address for the person named in 
the NME triplet and is optional. 

EVENT STATUS (EVS) - The EVS specifies the meeting status and is optional. 

TIME STAMP (TMS) - Only one TMS triplet is allowed in the MTG structure and it is optional. 

ENTRY SECURITY (ESL) - If this control is omitted the security level is PUBLIC. Only one ESL triplet is 
allowed in the MTG structure and it is optional. 

SET CODED GRAPHIC CHARACTER SET GLOBAL ID (SCG) - The SCG selects the character set and 
code page for characters contained in the triplets that follow the SCG in the calendar structure .The Network 
Address character set and code page are not affected by the SCG. The active code page is restored 
automatically at the end of the calendar structure. 

SUBJECT (SBJ) - The SBJ triplet contains character data describing the meeting subject. One SBJ 
triplet is allowed in each MTG structure and it is optional. 

PLACE (PLC) - The PLC triplet contains character data describing the meeting location. One PLC triplet 
is allowed in each MTG structure and is optional. 

DETAIL (DTL) - The DTL triplet contains character data describing the meeting. If the Code Page or 
character Set is changed in the meeting description, the DTL triplet must be ended, a SCG triple inserted, 
and another DTL triplet built. It is optional. 
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RSVP (RVP) - The RVP specifies the need for an attendance response from the meeting invitee and it 
is optional. 

if a MTG structure is received without all required triplets, an exception exists. The default action is to 
skip the structure and continue processing. If a MTG structure contains an unsupported or invalid triplet, an 
5 exception exists. The default action is to skip the triplet and continue processing. If a MTG structure 
contains a DTT triplet with dates and times not in ascending order or if the optional SCG triplet occurs at a 
position that does not immediately precede a triple with text data (DTL, SBJ, PLC), an exception exists. The 
default action, in both cases, is to ignore the triplet and continue processing. 



10 NAMES LIST (NML) DATA STRUCTURE 



The names list data structure is shown below. 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


0-1 


Structure Length 


NUM 




32767 


2 


R 


2 


Structure Typel 


COD 


X'D3' 


X'D3' 


1 


R 


3 


Structure Type2 


COD 


X'8A' 


X'8A' 


1 


R 


4-3 + n 


NML Triplets 




* 


* 


n 


R 


* Values depend on the triplet specification. 



The NML structure provides the fields to support a name, associated addresses and status. The NML 
may contain a list of items, such as an invitees list, by concatenating Name (NME), Address (ADR) and 
User Status (UST) sequences. The list may include one or more than one name and associated information. 

The following Valid NML Triplets for the NML DS were described in connection with the MTG structure. 

ERROR ACTION, STRUCTURE ID, TIME STAMP, ENTRY SECURITY, SET CGCSGID, NAME, USER 
STATUS, NETWORK ADDRESS and POSTAL ADDRESS. 

The Date and Time (DTT) triplet is not valid. 
The following triplet, however, is optional for the Names List data structure. 

NAMES LIST TYPE (NLT) - Only one NLT triplet is allowed in the Names List structure. The NLT triplet 
specifies the type of data contained in the Names List. If the NLT is not specified, the list contains a list of 
names and or status and/or addresses that are not necessarily in one of the categories defined by the NLT 
triplet. 

If an NML structure is received without a Structure ID triplet, an exception exists. The default action is to 
skip the structure and continue processing. If an NML structure contains an unsupported or invalid triplet, 
and exception exists. The default action is to skip the triplet and continue processing. Each sequence of the 
Names List structure triplets must occur in the listed order. 

Optional triplets may be omitted from any sequence. If a NML structure is received with a triplet out of 
sequence, an exception exists. The default action is to skip the structure and continue processing. The 
above-described processing for handling exceptions is standard for most structures and therefore can be 
assumed for the following items. 



50 



55 
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VIEW SELECT (VSL) DATA STRUCTURE 

The View Select data structure is shown below. 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


0-1 


Structure Length 


NUM 


* 


32767 


2 


R 


2 


Structure Typel 


COD 


X'D3' 


X'D3' 


1 


R 


3 


Structure Type2 


COD 


X'95' 


X , 95 1 


1 


R 


4-3 + n 


VSL Triplets 




* 


* 


n 


R 


* Values depend on the triplet specification. 



The VSL structure provides a way to request calendar views for specific category(s) and timespan(s). 
The Valid VSL Triplets previously described include the ERROR ACTION (EAC), USER DEFINED 
FIELD (UDF) and DATE and TIME (DTT) triplets. 
The following triplet is also optional and valid. 

ENTRY CATEGORY (ECT) - The ECT selects the category(s) for the calendar entry(s) to be selected in 
the view request. Only one ECT is allowed in a View Select structure. When more than one category is 
selected in the ECT, the view returned will contain the selected categories. If both the ECT and UDF triplet 
are omitted, all entries in the selected timespan will be returned. 

The DTT triplet dates and times must occur in ascending order. The first DTT processed must provide 
the earliest date and time block. The last DTT processed must provide the latest date and time block. The 
first DTT also provides the begin date and time for the timespan selected. 

When the optional ECT triplet is present, the VSL triplets must occur in the order ECT, DTT. 

AUTO RESPONSE (ARS) DATA STRUCTURE 

The Auto Response data structure is shown below. 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


0-1 


Structure Length 


NUM 


■ 


32767 


2 


R 


2 


Structure Typel 


COD 


X'D3' 


X'D3' 


1 


R 


3 


Structure Type2 


COD 


X'72' 


X'72' 


1 


R 


4-3 + n 


Auto Response Triplets 




* 




n 


R 



The ARS structure provides the fields necessary to interchange automatic response information. It 
allows the use of a network address (NAD), A Meeting or Appointment Structure ID (SID), A Priority (UDF) 
or a User Defined Field (UDF) specification to initiate an automatic response. 

The valid ARS triplets include the following: ERROR ACTION (EAC,) SET CGCSGID (SCG), STRUC- 
TURE ID (SID), NAME (NME), USER STATUS (UST), NET WORK ADDRESS (NAD), POSTAL ADDRESS 
(PAD), TIME STAMP (TMS), ENTRY SECURITY (ESL), USED DEFINED FIELD (UDF), RESPONSE (RSP). 

IF a NAD, a SID, A PRIORITY UDF, or A UDF, received as part of an invitation and request to attend an 
event being calendared, satisfy the established Auto Response criteria, the response specified by the RSP 
triplet is sent automatically. 

A separate ARS structure is required for each different set of ARS criteria. 

A NAD triplet may also be used to identify the individual that will receive an established automatic 
response. 

CALENDAR TRIPLETS DETAIL DESCRIPTION 

This section describes in detail the set of calendar triplets that are the building blocks designed to be 
used by the Calendar Structures of the system including those described in the previous section. 
The previous section indicated where these triplets are valid. 



20 
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The triplets are described in alphabetic order. 

In the triplet descriptions, bits are consecutively numbered from left to right starting with zero. 
The format for all of the triplets is the same and is shown below. 



5 



BYTES 


NAME 


| TYPE 


MIN 


max JlgthI opt ! 


! o 


LENGTH 


! NUM 




! ! r ! 


! i 


KEYWORD 


! COD 




! ! i r 


! 2 - n 


! PARM1 to PARMn 






I ! ! R 



75 where 

LENGTH = A one-byte value of the number of bytes in this triplet including byte zero. 
KEYWORD = a one-byte binary number that designates a specific triplet function. 
PARM1 to PARMn = Parameters containing the triplet settings. 

The length of some triplets can vary depending on the number of parameters specified. If the length 
20 excludes an optional parameter or part of an optional parameter, then the value for that parameter and any 
parameters that follow are not changed; that is, the LENGTH field is used as specified. If a triplet is 
received in which the length exceeds the maximum value required to include all parameters, an exception is 
raised since the additional values are considered to be unsupported parameters. Also, if the length field 
excludes a required parameter, an exception is raised. 
25 Since bytes 1 and 2 of all the triplets are identical, they are not shown for each triplet. Only bytes 2 
through n will be described. 

NETWORK ADDRESS (NAD) TRIPLET DATA STRUCTURE 
30 The NAD triplet data structure is shown below. 



35 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-n 


Network Address 


COD 




* 


16 


0 



The NAD triplet provides the Network Address for the item named in the (NME) triplet. 
The NAD Parameters include, 
40 NETWORK ADDRESS - This is the person's Network Address. 
Bytes 2 through 9 = USER ID 
BYTES 10 through 17 = NODE ID 

POSTAL ADDRESS (PAD) TRIPLET DATA STRUCTURE 

45 

The PAD triplet data structure is shown below. 



50 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-n 


Postal Address 


COD 


» 


* 


1-253 


0 



The PAD triplet provides the Postal Address for the item named in the (NME) triplet. 
55 The NAD Parameters include, 

POSTAL ADDRESS - This is the person's Postal Address. Valid values are valid characters in the active or 
selected code page. 
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PROCESS ID (PRD) TRIPLET DATA STRUCTURE 
The PRD triplet data structure is shown below. 



5 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-n 


Process 


COD 


* 




1-16 


0 



10 

The PRO triplet specifies the ID of a process such as a computer program. 
The PRO Parameters include, 
PROCESS -A 1 to 16 byte identifier. Valid values are valid characters in the active or selected code page. 

75 CALENDAR SCOPE (CSC) TRIPLET DATA STRUCTURE 

The CSC DS is shown below. 



25 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-3 


Calendar Begin Day 


NUM 


1 


366 


2 


R 


4-5 


Calendar Begin Year 


NUM 


-32K 


32767 


2 


R 


6-7 


Calendar End Day 


NUM 


1 


366 


2 


R j 


8-9 


Calendar End Year 


NUM 


-32K 


32767 


2 


R 



The CSC triplet defines the timespan supported by the calendar. 
CSC Parameters 

CALENDAR BEGIN DAY- The day of the year that the calendar timespan begins. 
CALENDAR BEGIN YEAR - This is the begin year for the timespan supported in the calendar. 
CALENDAR END DAY- The day of the year that the calendar timespan ends. 
CALENDAR END YEAR - This is the end year for the timespan supported in the calendar. 

CALENDAR TYPE (CTP) TRIPLET DATA STRUCTURE 

The CTP DS is shown below 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Type 


NUM 


0 


5 


1 


R 



The CTP triplet specifies the calendar type. It is only valid when used in the Calendar Profile. It defines 
how to present an entire calendar. 

50 

CTP Parameters 

TYPE - Specifies the calendar type such as Gregorian, Julian, Muhammadan, Jewish, Lunar, Shop. 

55 
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DATE AND TIME (DTT) TRIPLET DATA STRUCTURES 
The DTT DS is shown below. 



5 



15 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 


2 


Daylight Saving Indicator 


NUM 


0 


1 


1 


R 


3 


Time Zone Indicator 


NUM 


-23 


23 


1 


R 


4-5 


Begin Date Day 


NUM 


1 


366 


2 


R 


6-7 


Begin Date Year 


NUM 


-32K 


32767 


2 


R 


8-9 


Begin Time 


NUM 


0 


86400 


3 


R 


11 - 12 


End Date Day 


NUM 


1 


366 


2 


0 


13-14 


End Date Year 


NUM 


-32K 


32767 


2 


0 


15-17 


End Time 


NUM 


0 


86400 


3 


0 


18-254 


Additional Date/Time Combinations 



The DTT triplet specifies the dates and times for the associated triplets in the calendar structure. 
DTT Parameters 

DAYLIGHT SAVINGS INDICATOR - Specifies Daylight Savings Time is active. 
This parameter, in conjunction with the Time Zone, identifies the time zone and allows the correct time zone 
label (i.e., CST or CDT) to be applied to the time. 

TIME ZONE INDICATOR - The Time Zone Indicator is the displacement from Greenwich Mean Time 
(GMT) for the time specified. Values are specified in half hours from GMT to handle half-hour zones. 

BEGIN DATE DAY - The day of the year when the event begins. 
BEGIN DATE YEAR - The year the event begins. 
BEGIN TIME - Begin Time specifies the event start time in seconds. 
END DATE DAY - The day of the year when the event ends. 
END DATE YEAR - The year the event ends. 
END TIME - End Time specifies the event stop time in seconds. 

Date is specified as a combination of two, two byte parameters (day of the year and year). Time is local 
time in seconds beginning at midnight. One Begin Date and Begin Time is required in each DTT triplet. The 
Begin and End, Date and Time sequence may be repeated if additional begin and end date and begin and 
end times are needed. 

If more dates and times then can be sent in one DTT triplet are needed, additional DTT triplets can be 
included in the Calendar Structure. The only restriction is the byte structure length. 

DETAIL (DTL) DATA STRUCTURE 

The DTL DS is as follows. 



50 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-1 +n 


Character String 


COD 






n 


R 



The DTL triplet contains character data in the active or selected code page. 
DTL Parameters 

CHARACTER STRING - Text information associated with a calendar entry. 
Values are valid characters in the active or selected code page. 



30 



35 
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If the CGCSGID (SCG) is changed in a character string, the DTL triplet must be ended and another one 
built after inserting the SCG. 

ENTRY CATEGORY (ECT) DATA STRUCTURE 

5 

The ECT DS is shown below. 



! BYTES 


! NAME 


! TYPE 


1 MIN ! MAX |lGTH| 
i i ■ _ _ | 


OPT ! 


i ! $ I I I I i 

l i l l 1 
it ill » » „_ 


|2 - 5 


j Category 


| BST 


! ! ! 4 ! 


R ! 



75 

The ECT triplet provides a specific category for unavailable time and for open time on a calendar. The 
ECT triplet is used to specify calendar entry category(s) in requests and replies for both the Date and Time 
Map (DTM) and the View Select (VSL) structures. 

20 ECT Parameter 

CATEGORY - A four byte, bit encoded value. Combinations of more than one category bit are allowed. 
The categories provide both request and response categories for both Date and Time Map (DTM) and View 
Select (VSL) calendar structures. Bits 0 through 20 may be used for both DTM and VSL categories. Bits 21 
25 through 24 are used in View Select only. If they are used in a Date and Time Map, they are ignored. 

BIT SIGNIFICANCE ENCODING 





0 = 


Holiday (General) - The owner will work on this holiday. 


30 


1 = 


Holiday (Confirmed) - A confirmed calendar owner holiday. 




2 = 


Holiday (Tentative) - A tentative calendar owner holiday. 




3 = 


Vacation (Confirmed) - Confirmed calendar owner vacation. 




4 = 


Vacation (Tentative) - Tentative calendar owner vacation. 




5 = 


Offsite (Confirmed) - The calendar owner will not be at the normal work location and will 


35 




not be available. 




6 = 


Offsite (Tentative) - The calendar owner has tentatively scheduled an activity away from 
the normal work location. 




7 = 


Not Normal Work Hours - Categorizes hours that are not normally worked. 




8 = 


Confirmed Meetings (Not Attended) - The calendar owner will not attend. 


40 


9 = 


Confirmed Meetings (Attended) - The calendar owner will attend. 




to = 


Confirmed Meetings (May Attend) - The calendar owners status for this meeting is 
tentative. 




11 = 


Tentative Meetings (Not Attended) - The calendar owner will not attend. 




12 = 


Tentative Meetings (Attended) - The calendar owner will attend this meeting if it becomes 


45 




confirmed. 




13 = 


Tentative Meetings (May Attend) - The calendar owner's status for this meeting is 
tentative. 




14 = 


Confirmed Appointments (Not Attended) - The calendar owner will not attend. 




15 = 


Confirmed Appointments (Attended) - The calendar owner will attend. 


50 


16 = 


Confirmed Appointments (May Attend) - The calendar owner's status for this appointment 
is tentative. 




17 = 


Tentative Appointments (Not Attended) - The calendar owner will not attend. 




18 = 


Tentative Appointments (Attended) - The calendar owner will attend this appointment if it 
becomes confirmed. 


55 


19 = 


Tentative Appointments (May Attend) - The calendar owner's status for this appointment is 
tentative. 




20 = 


Non-Scheduled Time - Identifies open time on the calendar. This category is most 
effective if used alone. 
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21 a Date and Time Only (VIEW SELECT ONLY) - Selects date and time for all categories not 

specifically requested in a View Select. 

22 = Private Entry (VIEW SELECT ONLY) - Only date and time may be provided in the 

response to a calendar View Select request. 

23 = Calendar Comments (VIEW SELECT ONLY) - Character data entries. 

24 = Triggers (VIEW SELECT ONLY) - Entries that start a process and/or notify. 

25 - 31 = Reserved 

If all Category bits are set to one In a request for a Date and Time Map, the information returned is 
meaningless because it includes both scheduled and non-scheduled time. The "Non-Scheduled Time" bit 
should be used carefully if it is used with other bits to obtain meaningful data. The "Not Normal Work 
Hours" bit should also be used carefully for similar reasons. 

ENTRY CLASSIFICATION (ENC) DATA STRUCTURES 

The ENC DS is as follows 



! BYTES 


! NAME 


| TYPE 


MIN 


max Jlgth! 


OPT ! 




! 2 - 3 


I Classification 


J BST 




! ! 2 ! 


R 1 



The ENC triplet provides a specific Classification code for a calendar entry that occupies a block of 
time. 

ENC Parameters 

CLASSIFICATION - A two byte bit encoded value. Combinations of more than one Classification Bit are 
not allowed. 

BIT SIGNIFICANCE ENCODING 

0 = Holiday - (General) The owner will work on this holiday. 

1 = Holiday - (Confirmed) A confirmed calendar owner holiday. 

2 = Holiday - (Tentative) A tentative calendar owner holiday. 

3 = Vacation - (Confirmed) Confirmed calendar owner vacation. 

4 = Vacation - (Tentative) Tentative calendar owner vacation. 

5 = Offsite - (Confirmed) The calendar owner will not be at the normal work location and will not be 

unavailable. 

6 = Offsite - (Tentative) The calendar owner has tentatively scheduled an activity away from the 

normal work location. 

7 = Not Normal Work Hours - Identifies times that the calendar owner is normally not at work. 
ERROR ACTION (EAC) DATA STRUCTURE 

The EAC DS is as follows 



! BYTES 


| NAME 


' TYPE 


MIN 


MAX iLGTHj 


OPT ! 




! 2 


' Action 


1 BST 




! i ! 


R ! 



The EAC triplet specifies the action required when an exception is processed. 
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EAC Parameter 

ACTION - The error action specification. 

5 BIT 

0 = 0- (DEFAULT) Report the exception, take a default action and continue. 
0 = 1- Ignore the exception, take a default action and continue. 

An EAC triplet may occur at any place in a calendar structure. If an error action is not specified, the 
w default is to report the error, take a default action and continue. 

The Error Action specified in a calendar structure remains active only until the structure end, at which 
time, the default Error Action becomes active. 

EVENT STATUS (EVS) DATA STRUCTURE 

75 

The EVS DS is as follows. 



20 



BYTES 


! NAME 
l 


j TYPE 


' MIN 


MAX I LGTH j 


OPT 


i I i i i I 
t i i t I I 


2 


i 

J Event Status 


! BST 




! ! 1 ! 


R 



25 

The EVS triplet provides status for an event such as an appointment or meeting. 

EVS Parameter 

30 EVENT STATUS - The status of an event. 

BIT SIGNIFICANCE ENCODING 

0 = Confirmed (the meeting time has been established) 
35 1 = Tentative (the meeting is tentative) 

2 = Cancelled (the meeting was cancelled) 

3 = Postponed (the new date and time are not set) 

4 = Rescheduled (the meeting has been rescheduled) 

5 = Marked for Archive (entry will be saved for reference) 

40 

NAME (NME) DATA STRUCTURE 
The NME DS is as follows. 



45 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Name Type 


BST 






1 


R 


3 


Associated Triplets 


BST 




* 


1 


R 


4-n 


Item Name 


COD 


* 


* 


1-251 


R 



The NME triplet specifies a name of either a person or a calendar. 

55 
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NME Parameters 

NAME TYPE - Specifies the name type. Bits 1 and 2 are mutually exclusive. 
Only one of these bits may be set to 1 . 

5 

BIT SIGNIFICANCE ENCODING 

0 = (O-Name is a personal name), 

(1-Name is a calendar name). 
io 1 = 1- Name is a primitive name not unique in a network 

2 = 1- Name is a descriptive name unique in a network). 

3 - 7 = Reserved 

ASSOCIATED TRIPLETS - Bits set to 1 specify that User Status (UST), Network Address (NAD) and Postal 
Address (PAD) triplets may follow the NME triplet in any order. 
is 0 = A User Status (UST) triplet follows that specifies the named items role and status. 

1 = An Network Address (NAD) triplet follows that specifies the named item's network address(s) 

2 = A Postal Address (PAD) triplet follows that specifies the named item's postal address(s) 

ITEM NAME - Specifies the name of a person or calendar. Values are valid characters in the active or 
selected code page. The maximum name size is 251 bytes. 
20 The item named by the NME triplet may be further identified using the User Status (UST).the Postal 
Address (PAD) and the Network Address (NAD) triplets. 

The NME triplet must be preceded with an SCG triplet if the characters used are not on the active code 
page. 

25 NAMES LIST TYPE (NLT) DATA STRUCTURE 
The NLT DS is as follows. 



35 



! BYTES 


! NAME 


| TYPE 


MIN 


! max |lgth| 


OPT 




! 2 - 3 


List Type 


| BST 




! ! 2 J 


R 



The NLT triplet specifies the type of data contained in a list. 
NLT Parameter 

40 

LIST TYPE - Specifies the list type. Combinations of bits are allowed, and/or mail addresses. 

BIT SIGNIFICANCE ENCODING 

45 2 = 1 Name is a Nickname associated with a Network Address. 
2-15 Reserved. 
The lists may optionally contain postal addresses and user status. 
The NLT triplet describes the list contents for specific list types. Lists containing the NLT are constrained to 
the specified contents. If the NLT is omitted the lists may contain any valid combination of names, user 
50 status and addresses. 



55 
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PLACE (PLC) DATA STRUCTURE 
The PLC DS is as follows: 



5 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-n 


Location 


COD 


* 


* 


1-253 


R 



10 

The PLC triplet specifies a location for an event such as a meeting or appointment. The location is 
described using text characters. The maximum location length is limited to 253 text bytes. 

PLC Parameters 

75 

LOCATION - Location specifies the event location. 
RESPONSE (RSP) DATA STRUCTURE 
20 The RSP DS is as follows: 



25 



! BYTES 


! NAME 


! TYPE 


MIN 


MAX JlGTH, 


OPT 


ti I i I i i 
ii I t i i i 
i I I I I i i 


! 2 


! RESPONSE 


! BST 




! ! i ! 


R 



30 The RSP triplet establishes a response that will be sent automatically as part of the AUTO RESPONSE 
data structure. 

RSP Parameter 

35 RESPONSE- Specifies what response will be sent. The Alternate indication may use any other bit 
BIT SIGNIFICANCE ENCODING 

0 = No Action - Auto response is deactivated. 

1 = Confirmed - The invitee will attend. 

2 = Tentative - The invitee may attend. 

3 = Not Attending - The invitee will not attend. 

4 = User Acknowledge - The schedule request was received. 

5 = Alternate - The response is from the invitee's alternate. 

RSVP (RVP) DATA STRUCTURE 
The RVP DS is as follows: 



50 



55 



| BYTES 


! NAME 
i 


| TYPE 


MIN 


MAX iLGTHi 


OPT 


1 — i — — i i i i i 

ii i I I i I 
ii i i t I 1 
ii I I I i I 


! 2 


I 

! RSVP 


! BST 




1 ! i ! 


R 



The RVP triplet indicates that an attendance response is required. 



40 



45 
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RVP Parameter 

RSVP - Specifies the need for a response to a meeting schedule request. 
5 BIT SIGNIFICANCE ENCODING 

0 = No attendance response is required. 

1 = An attendance response is required using the NML structure. 

w SET CODED GRAPHIC CHARACTER SET GLOBAL ID (SCG) DATA STRUCTURE 
The SCG DS is as follows: 



75 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-3 


GCSGID 


NUM 


1 


65534 


2 


R 


4-5 


CPGID 


NUM 


1 


65534 


2 


R 



The SCG triplet specifies the coded graphic character set global identification that is used to map 
subsequent text into presentable graphics. 

The CGCSGID that is specified by the system selects the active Character Set and Code Page. If the 
CGCSGID is not specified the default Character Set and Code Page specified are used. 

SCG Parameters 

CGCSGID - Coded Graphic Character Set Global ID; a concatenation of 2 two-byte numbers. The first 
two bytes identify the Graphic Character Set Global ID (GCSGID) expressed as a binary value. The second 
two bytes identify the Code Page Global ID (CPGID) expressed as a binary value. 
GCSGID - Graphic Character Set Global ID. 
CPGID - Code Page Global ID. 

GCSGID and CPGID are used to determine how coded text characters are translated to the graphic 
characters to be presented. 

The SCG will only select a code page for the triplet that immediately follows it. If structures containing 
text characters on a code page that is different from the default code page are concatenated, a separate 
SCG is required preceding each structure. 

The SCG has no affect on the NETWORK ADDRESS in the UDF triplet and the USER CODE in the 
UDF triplet. 

STRUCTURE ID (SID) DATA STRUCTURE 
The SID DS is as follows: 

45 



50 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


ID Type 


BST 






1 


R 


3-n 


Identifier 


COD 


* 


• 


n 


R 



The SID triplet provides an identifier for calendar structures. 
55 SID Parameters 

ID TYPE - Specifies the ID type 



35 
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BIT SIGNIFICANCE ENCODING 

0 = Entry ID - Identifies a calendar entry 

1 = Names List ID - Identifies a list of names 

2 = Trigger ID - Identifies a trigger 

3 = Profile ID - Identifies a calendar profile 

4 = Auto Response - Identifies an automatic response 
IDENTIFIER - 1 to 44 character Identifier. 

The SID provides a correlation ID to accomplish calendar updates from an Intelligent workstation to a 
host, to correlate responses to a meeting notice with the meeting names list and to correlate notification of a 
list of people associated with a meeting or a list. 

SUBJECT (SBJ) DATA STRUCTURE 

75 The SBJ DS is as follows: 



20 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2-n 


Event Subject 


COD 


a 


* 


1-253 


R 



The SBJ triplet specifies the subject for an event. The subject is described using text character. 
SBJ Parameters 

EVENT SUBJECT - This parameter specifies the event subject. 
TIME STAMP (TMS) DATA STRUCTURE 

The TMS DS is as follows. 



35 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Daylight Savings Indicator 


NUM 


0 


1 


1 


R 


3 


Time Zone Indicator 


NUM 


-23 


23 


1 


R 


4-5 


Begin Date Day 


NUM 


1 


366 


2 


R 


6-7 


Begin Date Year 


NUM 


-32K 


32767 


2 


R 


8-10 


Begin Time 


NUM 


0 


86400 


3 


R 


11 


Network Address Length 


NUM 


0 


128 


1 


0 


12-n 


Network Address 


COD 






~128 


0 



The TMS triplet specifies an entry's time zone, creation date and time and the entry creator's network 
address. 

50 

TMS Parameters 

DAYLIGHT SAVINGS INDICATOR - Specifies Daylight Savings Time is active. This parameter, in 
conjunction with the Time Zone, identifies the time zone and allows the correct time zone label (i.e.,. CST or 
55 CDT) to be applied to the time. 

TIME ZONE INDICATOR - The Time Zone Indicator is the displacement from Greenwich Mean Time 
(GMT) for the time specified. Values are specified in half hours from GMT to handle half hour zones. 



5 



70 



25 



30 
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BEGIN DATE YEAR - The year the event begins. 
BEGIN TIME - Begin Time specifies the event start time. 
NETWORK ADDRESS LENGTH - The Network Address length 
NETWORK ADDRESS - System address 
5 Bytes 12 thru 19 = USER ID - valid characters in CP256, CS930. 

Bytes 20 thru 27 = NODE ID - valid characters in CP256, CS930. 

Bytes 28 thru 139 = Reserved to support additional address. 

USER DEFINED FIELD (UDF) DATA STRUCTURE 

10 ~~~ 
The UDF DS is as follows: 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Priority 


NUM 


1 


10 


1 


R 


2-9 


User Code 


COD 


* 


* 


1-8 


R 



The UDF triplet provides a priority and user defined field that is assigned by the calendar owner. The 
assigned code provides additional entry categories. 

UDF Parameters 

PRIORITY - A one byte field that specifies a priority value for a calendar entry. 1 is the highest and 10 
is the lowest priority. 

USER CODE - An eight byte user defined code. 

USER STATUS (UST) DATA STRUCTURE 

The UST DS is as follows: 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Role 


COD 


0 


7 


1 


R 


3 


Personal Status 


COD 


0 


5 


1 


R 



40 

The UST triplet provides information regarding the person named in the Name (NME) triplet. It provides 
the named persons Role and Personal Status. 



UST Parameters 

45 

ROLE - Specifies the persons role regarding the event. 



VALUES 




50 0 




Caller - Person has called the event. 


1 




Arranger - Person is arranging the event. 


2 


S3 


Invitee (Default) - Person has been invited to the event. 


3 




Mandatory Invitee - Person who must attend the meeting. 


4 




Alternate - Person replacing an invitee for attendance consideration. 


55 5 




Additional Attendee - Person who is adding themselves to the distribution fist associated with a 






group meeting. 


6 




Receives Copy - Person who receives event information. 


7 




Receives Blind Copy - Person who receives event information only, whose name will not appear 



25 
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on the distribution list. 
PERSONAL STATUS - The status associated with the name. 



VALUES 



70 



0 = No Action (no status has been received) 

1 = Confirmed (the person will attend) 

2 = Tentative (the person might attend) 

3 = Not Attending (the person will not attend) 

4 = User Acknowledge (received the invitation) 

5 = Alternate (the invitee will not attend, but an alternate may) 

WORK TIMES (WTM) DATA STRUCTURE 



75 



The WTM DS is as follows: 



20 



25 



BYTES 


NAME 


TYPE 


MIN 


MAX 


LGTH 


OPT 
















2 


Daylight Savings Indicator 


NUM 


0 


1 


1 


R 


3 


Time Zone Indicator 


NUM 


-23 


23 


1 


R 


4-6 


Begin Time 


NUM 


0 


86400 


3 


R 


7-9 


End Time 


NUM 


0 


86400 


3 


R 


! 10-254 


Additional Begin/End Time Combinations 



The WTM triplet specifies the work times for an associated calendar. Time is local time in seconds 
30 beginning at midnight. 

WTM Parameters 



35 



40 



45 



50 
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DAYLIGHT SAVINGS INDICATOR - Specifies Daylight Savings Time is active. This parameter, in 
conjunction with the Time Zone, identifies the time zone and allows the correct time zone label (i.e., CST or 
CDT) to be applied to the time. 

TIME ZONE INDICATOR - The Time Zone Indicator is the displacement from Greenwich Mean Time 
(GMT) for the time specified. Values are specified in half hours from GMT to handle half hour zones. 

BEGIN TIME - Begin Time specifies the time block begin in seconds. 

END TIME - End Time specifies the time block end in seconds. 

One Begin Time and End Time is required in each WTM triplet. The Begin and End Time sequence 
may be repeated if additional begin and end times are needed. 

Fig. 3a shows a screen that is displayed to the operator/calendar owner in response to the operator 
indicating to the system that he wants to calendar an event. This can be accomplished, for example, by 
selecting item 1 from the master menu shown in Fig. 4a. Assume that a meeting is scheduled at 10 a.m. on 
Thursday, October 7, 1986, and that the notice for the meeting is to be issued through the electronic 
calendaring system. The owner then enters the information into the system, employing the screens of Figs. 
4b and 4c. To identify the event type after selecting option 1 on screen 4a, the operator merely presses the 
inner key since the cursor has automatically been positioned at the event e.g., "meeting" on the screen of 
Fig. 3b. The next data entry as shown involves assigning a priority to this event. The valued to be entered is 
a value from 1-10 as indicated on the line following the blank for the value. The function of the priority 
numbers to establish the relative importance of this event when viewed with regard to other commitments 
which are either planned or anticipated. This entry of a priority value is optional since the system will 
establish a default priority for the event according to some predetermined criteria which has been 
established for all calendar owners or alternately which gives you a unique default for each specific 
individual. 

The assignment of a priority value to a calendar event either explicitly by the calendar owner or 
implicitly by the system is a necessary step in the view select process. The user defined field, as shown in 
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Fig. 4b is not used in the present example. Its function is to provide a field which the user or the user 
community can employ for some predefined purpose. The event identifier is the official name of the 
meeting. The date and time of the meeting are entered next. 

The next entry on the screen is the names list. All the persons that are invited to attend the meeting 
5 have been listed in a names list along with their user ID, network and/or postal addresses and that list is 
assigned a name. The information is stored in the names list data structure described earlier so that in the 
case of regularly scheduled meetings, the meeting caller only needs to identify the name of the names list. 

The next entry is for the name of the person calling the meeting. The last two entries are to identify the 
subject of the meeting and its physical location, such as a conference room. 
10 Fig. 4c is the last screen employed in calendaring an event. This screen allows an event to be assigned 
a security classification and to indicate if the meeting is tentative or confirmed. The remaining portion of the 
screen shown in Fig. 4c is for establishing a trigger reminder for the event. 

After all the data is entered defining the event, the calendar owner advises the system to send the 
meeting information that has just been entered to each of the individuals listed in the names lists. This is 
75 done in the example shown by keying the program function key PF5. 

The data defining the meeting particulars that were entered into the system is stored in the appropriate 
data structures and triplets described earlier. These data structures are transmitted to each invitee on the 
system in accordance with the protocols established for the calendaring system and the inter-system 
communication protocols that can accommodate data interchange between two different calendaring 
20 systems. 

The invitee calendar owner is required to respond to the meeting notice since every meeting notice 
contains an RVP triple indicating that a response is required. 

If the invitee/owner has not established an automatic response for this notice, then the response must 
be entered manually. Any of the prior art methods for manually responding to a meeting notice by the 

25 invitee may be employed. For example, the screen employed for calendaring an event or one similar to that 
screen, may be presented to the invitee with the program function key programmed to enter the invitees* 
response. Alternately a special screen can be presented providing a response field for the event. The 
response that is entered is stored in the personal status field of the user status triplet that is associated with 
the invitees' name in the names list. That data structure is returned to the meeting caller and stored in the 

30 names list data structure for the identified meeting. 

It should be assumed in the following discussion that a calendar owner has decided for a number of 
reasons that invitations or requests for involvement in events being calendared by selected calendar owners 
or selected meetings and appointments or other criteria are to be responded automatically. In order to 
establish automatic responses, the calendar owner selects item 5 from the master menu shown in Fig. 4a. 

35 The auto response screen, shown in Fig. 3, is then presented. If the invitee decides that he will always 
attend the meetings that are identified by "D35 Meeting A1 " then that ID is entered on the line in Fig. 3 
following the legend Meeting Name. 

The invitee also enters the response that he wants sent which, in accordance with the initial assumption, 
is that he will always attend. The data that is entered into the system interactively when the auto-response 

40 screen is being displayed is stored in the Automatic Response data structure ARS previously described. By 
pressing program function key PF12 a second set of data for an automatic response can be entered. The 
system is designed to accommodate a reasonable number of criteria sets. Entry of more than one criteria in 
frame 3 is interpreted by the system as a "logical and" situation in that a notice must contain all the criteria 
that was entered on the one screen before the response will be automatically dispatch. 

45 The system is arranged so that the host maintains each calendar owner's calendar so that when the 
owner's workstation is not turned on, his calendar is still available to the other individuals on the system. 
When a meeting notice is sent to the invitee, the system first checks to see if that invitee/owner has 
established any automatic response entries. If the system finds that automatic response structures exist, 
then a comparison is made between the data contained in the meeting notice and the data entered as 

so criteria in the auto-response data structure. Specifically, the meeting name i.e., the event identifier for the 
meeting notice, is compared against the data entered in the ARS data structure in the identifier field of the 
SID triplet. In a similar manner, the user status triplet associated with the names list identifies the meeting 
caller by the placement of a 0 in the row field of that triplet. The name of the meeting caller is then 
compared against the name and user status triplet associated with the ARS data structure, this name having 

55 been previously stored in this data structure when the invitee was entering criteria in the Automatic 
Response frame. When the comparison operation indicates a match, then the response stored in the 
personal status field of the User Status data structure associated with the ARS structure is sent to the 
meeting caller automatically. 
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The above-described operation has been summarized in the flow chart of Fig. 5. 

The following listing of programming type statements in pseudo code is provided to enable those 
persons skilled in the art of programming interactive type systems to have a detailed understanding of the 
various steps that are involved in providing an automatic response in an electronic calendaring system. 
5 The first section is directed to the process of establishing criteria by the calendar owner which will 
provide the automatic response to an invitation to attend a meeting being called by another calendar owner. 
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2 
2 



.DO 

.Select the Automatic Response in the master menu and hit 
enter 
•ENDDO 

•DO UNTIL 

.Enter any combination of Meeting ID, Meeting Caller Name, 
User ID, System ID, Used Defined Field, and User Priority 
..DO 

..Select and enter a response number (0=No Response ;l=Confirmed 
(Will Attend); 2=Tentative (May Attend) ; 3=Not Attending: 
4=User Acknowledge; 5=Alternate 

. .ENDDO 



30 The following code is directed to the process of developing an automatic response to a meeting notice. It 
begins with the receipt of a meeting notice. The automatic response does not consider whether the meeting 
is tentative or confirmed if the calendaring method permits the meeting to be so classified. Both are 
handled in the same manner. 
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.Do 

.Compare the received Meeting notice data to the Auto response 
criteria that is stored in the Automatic Response Structure 
. ENDDO 

.IF the established criteria matches meeting notice data 
-THEN 

Set up the associated response in the Automatic Response 
Structure. Place the meeting notice data on the receivers 
calendar with the appropriate meeting status (confirmed or 
tentative) 

Establish the response status in the meeting's Names List 
.Else place the meeting notice in the receivers mail queue and 
notify owner of meeting request 
.ENDIP 

.IF an automatic response other than User Acknowledge was 
setup 

.THEN Send back the Automatic Response Structure to the 
Meeting Caller 

.Else Send back a User Acknowledge 
.ENDIF 

35 

Claims 

1. A calendaring method for use in a data processing system having a plurality of interactive type work 
40 stations connected directly or indirectly to a host processing unit and in which a first calendar owner 

receives a response from a second calendar owner as a result of an event notice sent through said 
system to said second calendar owner at the time said first owner is calendaring an event, said method 
selectively developing said response automatically, based on criteria that are pre-established by said 
second owner, said method comprising the steps of: 
45 a) establishing a first data structure for use by said system during the calendaring of an event by 

said first owner including a plurality of fields for storing data relevant to said event, 

b) establishing a second data structure for later use by said system in developing an automatic 
response upon receiving an event notice from said first owner, said second data structure including 
a plurality of predefined fields for storing data when they are entered into said system by said 

so second owner, said data including criteria type data and response type data, 

c) comparing said criteria type data stored in said second data structure with data stored in said first 
data structure when said event notice is received by said second owner, and 

d) developing said response automatically when said comparing step indicates a predetermined 
relationship between one or more of said criteria type data and the corresponding respective data 

55 stored in said first data structure. 

2. A method according to Claim 1 in which said step of developing said response automatically includes 
the step of responding to said first calendar owner in accordance with the response data stored in said 
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second data structure. 

3. A method according to Claim 1 or Claim 2 in which each said workstation includes a display and 
keyboard and further including the step of displaying to said second calendar owner a criteria screen to 

5 assist said second owner to interactively enter said criteria type data and said response type data into 
said system through said keyboard. 

4. A method according to Claim 3 further including the step of displaying to said first calendar owner a 
screen to assist said first owner to interactively enter said data relevant to said event through said 

10 keyboard. 

5. A method according to any one of Claims 1 to 4 further including the step of storing said criteria type 
data and said response type data entered into said system by said second owner in said plurality of 
predefined fields of said second data structure. 

6. A method according to any one of Claims 1 to 5 further including the step of storing said data relevant 
to said event entered into said system by said first owner in said plurality of fields of said first data 
structure. 

20 7. A method according to any one of Claims 1 to 6 in which said step of establishing said first data 
structure includes the step of establishing an event identifier field for storing a unique identifier for an 
event at the time said event is being calendared and said step of establishing said second data 
structure further includes the step of establishing one of said predefined fields for storing an event 
identifier as one of said criteria type data. 

25 

8. A method according to Claim 7 in which said step of establishing said first data structure further 
includes the step of establishing an event caller name field for storing the name of the individual calling 
the event that is being calendared, and said step of establishing said second data structure further 
includes the step of establishing one of said predefined fields for storing the name of the event caller 

30 as one of said criteria type data. 

9. A method according to any one of Claims 1 to 8 in which said step of entering response type data into 
said system further includes the step of selecting one of a plurality of predefined responses, each of 
which reflects said second owner's intention relative to attending said event. 

35 

10. A method according to Claim 9 further including the step of displaying to said second owner a plurality 
of criteria screens to assist said second owner to interactively enter more than one set of criteria type 
data and said response type data into said system through said keyboard to permit the development of 
automatic responses based on different sets of criteria. 

40 

PatentansprUche 

1. Ein Verfahren zur Kalendererstellung zur Verwendung in einem Datenverarbeitungssystem, das eine 
Vielzahl von einer Art von interaktiven Workstations hat, die direkt Oder indirekt an einen Hauptrechner 

45 angeschlossen sind und in dem ein erster KalendereigentOmer eine Antwort von einem zweiten 
KalendereigentUmer als Ergebnis einer Notiz Uber ein Ereignis empfangt, die mittels dieses Systems 
an den zweiten KalendereigentUmer zu dem Zeitpunkt gesendet wird, an dem der erste Kalendereigen- 
tUmer ein Ereignis kalendermaBig erfaBt, wobei dieses Verfahren selektiv die automatische Antwort 
herstellt, basierend auf Kriterien, die zuvor von dem zweiten EigentUmer erstellt wurden, wobei das 

so Verfahren folgende Schritte enthSIt: 

a) Erstellen einer ersten Datenstruktur zur Verwendung in diesem System wahrend der Kalenderer- 
stellung eines Ereignisses durch den ersten EigentUmer, die eine Vielzahl von Feldern zur Speiche- 
rung von Daten enthalt, die fUr das Ereignis wichtig sind, 

b) Erstellen einer zweiten Datenstruktur zur spSteren Verwendung durch das System zur Herstellung 
55 einer automatischen Antwort nach Erhalt der Notiz Uber ein Ereignis von dem ersten EigentUmer, 

wobei die zweite Datenstruktur eine Vielzahl von vordefinierten Feldern zur Speicherung von Daten 
enthalt, wenn sie durch den zweiten EigentUmer in dieses System eingegeben werden, wobei diese 
Daten eine Art von Kriterien- und Antwortdaten enthalten, 
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c) Vergleich der Art von Kriteriendaten, die in der zweiten Datenstruktur gespeichert wurden mit 
Daten, die in der ersten Datenstruktur gespeichert wurden, wenn der zweite EigentOmer die Notiz 
Uber ein Ereignis empfangen hat, und 

d) Herstellung der automatischen Antwort, wenn sich bei dem Vergleich herausstellt, daB ein zuvor 
5 bestimmtes Verhaltnis zwischen einer Oder mehreren der Art(en) von Kriteriendaten und den 

entsprechenden, jeweiligen Daten besteht, die in der ersten Datenstruktur gespeichert wurden. 

2. Ein Verfahren gemaB Anspruch 1, in dem der Schritt zur Herstellung der automatischen Antwort den 
Schritt enthSft, dem ersten KalendereigentOmer gemaB der in der zweiten Datenstruktur gespeicherten 
w Antwortdaten zu antworten. 

a Ein Verfahren gemaB Anspruch 1 oder Anspruch 2, in dem die Workstation eine Anzeige und eine 
Tastatur enthSIt und auBerdem den Schritt enthalt, dem zweiten KalendereigentOmer einen Bildschirm 
mit Kriterien anzuzeigen, der dem zweiten EigentOmer hilft, die Art von Kriteriendaten und Antwortdaten 
15 mittels der Tastatur interaktiv in das System einzugeben. 

4. Ein Verfahren gemSB Anspruch 3, das auBerdem den Schritt enthSIt, dem ersten KalendereigentOmer 
einen Bildschirm anzuzeigen, der dem ersten EigentOmer hilft, die fOr das Ereignis relevanten Daten 
mittels der Tastatur interaktiv einzugeben. 

20 

5. Ein Verfahren gemaB irgendeinem der AnsprOche 1 bis 4, das auBerdem den Schritt enthSIt, die Art 
von Kriteriendaten und Antwortdaten zu speichem, die von dem zweiten EigentOmer in die Vielzahl von 
zuvor definierten Feldern der zweiten Datenstruktur eingegeben wurden. 

25 6. Ein Verfahren gemaB irgendeinem der AnsprOche 1 bis 5, das auBerdem den Schritt enthalt, die fOr 
das Ereignis relevanten Daten zu speichern, die von dem ersten EigentOmer in die Vielzahl von Feldern 
der ersten Datenstruktur eingegeben wurden. 

7. Ein Verfahren gemaB irgendeinem der AnsprOche 1 bis 6, in dem der Schritt zur Erstellung der ersten 
30 Datenstruktur den Schritt zur Erstellung eines Ereigniskennzeichenfeldes zur Speicherung eines einzel- 
nen Kennzeichens fOr ein Ereignis zu dem Zeitpunkt enthalt, an dem das Ereignis kalendermaBig 
erstellt wird und der Schritt zur Erstellung der zweiten Datenstruktur auBerdem den Schritt zur 
Erstellung eines der zuvor definierten Felder zur Speicherung eines Ereigniskennzeichens als eines der 
Kriteriendaten enthalt. 

35 

a Ein Verfahren gemaB Anspruch 7, in dem der Schritt zur Erstellung der ersten Datenstruktur auBerdem 
den Schritt zur Erstellung eines Feldes fOr den Namen des Veranstalters des Ereignisses zur 
Speicherung des Namens der Person enthalt, die das Ereignis einberuft, das kalendermaBig erstellt 
wird und der Schritt zu Erstellung der zweiten Datenstruktur auBerdem den Schritt zur Erstellung eines 
40 der zuvor definierten Felder enthSIt, urn den Namen des Veranstalters des Ereignisses als eines der 
Kriteriendaten zu speichern. 

9. Ein Verfahren gemaB irgendeinem der AnsprOche 1 bis 8, in dem der Schritt zur Eingabe von einer Art 
von Antwortdaten in das System auBerdem den Schritt enthSIt, aus einer Vielzahl von zuvor festgeleg- 

45 ten Antworten eine auszuwShlen, wobei jede die Absicht des zweiten KalendereigentOmers bezogen auf 
die Anwesenheit bei diesem Ereignis reflektiert. 

10. Ein Verfahren gemaB Anspruch 9, das auBerdem den Schritt enthalt, dem zweiten EigentOmer eine 
Vielzahl von Bildschirmen mit Kriterien anzuzeigen, die dem zweiten EigentOmer helfen, mehr als einen 

so Satz von Kriteriendaten und Antwortdaten mittels der Tastatur in das System interaktiv einzugeben, urn 
die Herstellung von automatischen Antworten basierend auf verschiedenen Kriteriensatzen zu erlauben. 

Revendications 

55 1. Un procede" de gestion d'un calendrier a utiliser dans un systeme de traitement de donnSes comportant 
une plurality de stations de travail du type interactif connecters directement ou indirectement a une 
unite* de traitement note et dans lequel un premier gestionnaire de calendrier regoit une r^ponse d'un 
second gestionnaire de calendrier a la suite de renvoi d'une notification d^venement dans ledit 
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systeme audit second gestionnaire de calendrier a I'instant ou le premier gestionnaire est en train 
d'inscrire un Svenement au calendrier, ledit procSdS dSveloppant sSlectivement et automatiquement 
ladite rSponse en se basant sur des criteres qui sont prS-Stablis par ledit second gestionnaire, ledit 
procSdS comprenant les Stapes suivantes: 
5 a) I'Stablissement d'une premiere structure de donnSes a utiliser par ledit systeme pendant 

I'inscription au calendrier d'un Svenement par ledit premier gestionnaire, comprenant une plurality 

de champs pour emmagasiner des donnSes relatives audit Svenement, 

b) I'Stablissement d'une seconde structure de donnSes pour une utilisation ultSrieure par ledit 
systeme pour le dSveloppement d'une rSponse automatique a la reception d'une notification 

10 d'Svenement depuis ledit premier gestionnaire, ladite seconde structure de donnSes comprenant une 

pluralitS de champs prSdefinis pour emmagasiner des donnSes lorsqu'elles sont entries dans ledit 
systeme par ledit second gestionnaire, lesdites donnSes comprenant des donnSes du type critere et 
des donnSes du type rSponse, 

c) la comparaison desdites donnSes du type critere emmagasinSes dans ladite seconde structure de 
75 donnSes avec des donnSes emmagasinSes dans ladite premiere structure de donnSes lorsque ladite 

notification d'SvSnement est rogue par le second gestionnaire, et 

d) le dSveloppement automatique de ladite rSponse lorsque ladite Stape de comparaison indique 
une relation prSdSterminSe entre une ou plusieurs desdites donnSes du type critere et les donnSes 
respectives correspondantes emmagasinSes dans ladite premiere structure de donnSes. 

20 

2. Un precede" selon la revendication 1 dans lequel ladite Stape de developpement automatique de ladite 
rSponse comprend I'Stape de rSponse audit premier gestionnaire de calendrier selon les donnSes de 
rSponse emmagasinSes dans ladite seconde structure de donnSes. 

25 3. Un procSdS selon la revendication 1 ou 2 dans lequel chacune desdites stations de travail comprend un 
affichage et un Scran, et qui comprend en outre I'Stape d'affichage pour ledit second gestionnaire de 
calendrier d'un Scran de critere pour faci liter I'entrSe interactive desdites donnSes du type critere et 
desdites donnSes du type rSponse dans ledit systeme par ledit second gestionnaire par I'intermSdiaire 
dudit clavier. 

30 

4. Un procSdS selon la revendication 3 comprenant en outre I'Stape d'affichage d'un Scran pour ledit 
premier gestionnaire de calendrier afin de faciliter I'entrSe interactive desdites donnSes relatives audit 
SvSnement par ledit premier gestionnaire au travers dudit clavier. 

35 5. Un procSdS selon Tune quelconque des revendications 1 a 4 comprenant en outre I'Stape d'emmagasi- 
nage desdites donnSes du type critere et desdites donnSes du type rSponse entrSes dans ledit 
systeme par ledit second gestionnaire dans ladite pluralitS de champs prSdSfinis de ladite seconde 
structure de donnSes. 

40 6. Un procSdS selon I'une quelconque des revendications 1 a 5 comprenant en outre I'Stape d'emmagasi- 
nage desdites donnSes relatives audit Svenement entrSes dans ledit systeme par ledit premier 
gestionnaire dans ladite pluralitS de champs de ladite premiere structure de donnSes. 

7. Un procSdS selon I'une quelconque des revendications 1 a 6 dans lequel ladite Stape d'Stablissement 
45 de ladite premiere structure de donnSes comprend I'Stape d'Stablissement d'un champ d'identification 

d'Svenement pour emmagasiner une identification unique d'un SvSnement a I'instant oCt ledit Svene- 
ment est inscrit au calendrier et dans lequel ladite Stape d'Stablissement de ladite seconde structure de 
donnSes comprend en outre I'Stape d'Stablissement de Tun desdits champs prSdefinis pour emmagasi- 
ner une identification d'SvSnement comme I'une desdites donnSes du type critere. 

50 

8. Un procSdS selon la revendication 7 dans lequel ladite Stape d'Stablissement de ladite premiere 
structure de donnSes comprend en outre I'Stape d'Stablissement d'un champ de nom de demandeur 
d'Svenement pour emmagasiner le nom de la personne appelant I'Svenement qui est en cours 
d'inscription au calendrier, et dans lequel ladite Stape d'Stablissement de ladite seconde structure de 

55 donnSes comprend en outre I'Stape d'Stablissement de Tun desdits champs prSdSfinis pour emmagasi- 
ner le nom du demandeur d'SvSnement comme I'une desdites donnSes du type critere. 
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9. Un proc£d§ selon Tune quelconque des revendications 1 a 8 dans lequel ladite etape d'entrSe de 
donnees du typ8 r^ponse dans ledit systfcme comprend en outre PStape de selection de Tune d'une 
plurality de rSponses pr6d6finies, chacune d'elles reflechissant I'intention dudit second gestionnaire 
relative au suivi dudit 6v6nement. 

5 

10. Un proc£d§ selon la revendication 9 comprenant en outre I'gtape d'affichage pour ledit second 
gestionnaire d'une plurality d'^crans de critere afin de faci liter Tentrge interactive par ledit second 
gestionnaire de plus d'un ensemble de donnees du type crit&re et desdites donnees de type rSponse 
dans ledit systfcme au travers dudit clavier pour permettre le dSveloppement de rSponses automatiques 

70 bashes sur des ensembles differents de criteres. 
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ENTER THE RESPONSE INITIATORS ) 

MEETING NAME : 

MEETING CALLERS' NAME: 

USER ID: 

SYSTEM ID: 

USER DEFINED FIELD: 

USER DEFINED PRIORITY: 



(Pick one or more) 



ENTER THE RESPONSE 



■ No Action 

=» Confirmed (will attend) 

- Tentative (nay attend) 

- Not Attending 

=» User Acknowledge (acknowledge invitation) 
» Alternate (the response is for an alternate) 



ENTER THE ALTERNATE: 

NAME: 

USER ID: 

SYSTEM ID: 

POSTAL ADDRESS: 



PFl=»H«lp PF3»Cancel PFll'Add One Line 

PF9=File PF12-File and Display the next Auto Response Template 

FIG. 3 



MOVE THE CURSOR TO EACH SELECTION OR KEY THE ITEM DIRECTLY AND HIT ENTE 

1. Calendar Entry, Meeting, 
Appointment, Trigger, 
Note, Vacation, 
Holiday, Offsite, 
Not Normal Work Hours 

2. View Select 

3. Composite Calendar 

4. Conference Room 

5. Automatic Response 



Month 






Year 
1 2 


3 4 
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7 8 9 
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Command: 



PFl=»Help PF2=Return to System 



FIG. 4a 
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MOVE THE CURSOR TO EACH SELECTION OR KEY THE ITEM DIRECTLY THEN HIT ENTER 
Classification List: 1 Meeting 2 Appointment 3 Offsite A Vacation 5 Holiday 
6 Note 7 Not Normal Work Hours 

CLASSIFICATION: 1 (Select one classification number from the above list) 

USER DEFINED FIELD (8 characters) 

PRIORITY 02 ( 1 *highes t , 1 0»lowes t ) 
EVENT IDENTIFIER: D35 MEETING Al 
MEETING/ APPOINTMENT INFORMATION: 

Date 10/07/86 Start Time: 1:15 PM End Time: 5:00 PM 

Date 10/09/86 R2 Start Time: 8: 30 PM End Time: 5:00 PM 
(Rx after Date will repeat the event at the same time, x number of days) 
Names List : D35 NAMES Al 

Caller : TOM ROBERTS 

Subject : 1987 Budget ' 

Place : Conference Room 128F 

Details :_ 



PFl-Help PF3*Cancel PF5-Send Notice PF6«Begin Search 

PF8=*Next Screen(Security, Status, Trigger) PF9*File PFll»Add One Line 



FIG. Ab 



MOVE THE CURSOR TO EACH SELECTION OR KEY THE ITEM DIRECTLY AND HIT ENTER 

SECURITY: Public Shared Private 

(pick one) 

STATUS: Tentative Confirmed 

(pick one) 

TRIGGER: Message Audio Process 

(All three may be picked) 

Date; 10/07/86 Time: 1:00 PM 

Date: 10/09/86 Time: 8:00 AM 

(PF11 will scroll and add additional Date Lines while on the Date line) 
(Rx after Date will repeat the event at the same time, x number of days) 
Names Li st: J)35/AUSVM1_( Enter The Notification List VNET Address) 

Message : The department meeting starts in 15 minutes 

TPF11 will add one line) 

Process : INVEST01/AUSVM1 Enter The Process VNET Address 

Pick up these calculations before the Budget Meeting 

TRIGGER FIXED OR FLOAT? Fixed Float 

(pick one) 

Float with Event Identifier: D35 MEETING Al 
(If this event moves, the trigger will be moved to the same relative time) 

PFl=Help PF3»Cancel PF5=»Send Notice PF6»Begin Search 
PF7»Previous Screen PF8=Next Screen PF9-File PFIO-Add One Line 



FIG. AC 
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OR 
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FIG. 5 
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